REMARKS 



This paper is responsive to a Final Office Action mailed July 
10, 2008. Prior to this response, claims 1-4, 7-8, 11-15, 18-19, 22-25, 28, 
31-35, 38, and 41-44 were pending. After amending claim 44, claims 1-4, 
7-8, 11-15, 18-19, 22-25, 28, 31-35, 38, and 41-44 remain pending. 

In Section 2 of the Office Action, claim 44 is objected to 
because of an informality. In response, the Applicant has amended claim 
44 to depend from claim 12, instead of previously canceled claim 20. 

In Section 3 .of the>Office Action claims 22 and 32, and claims 
dependent from these claims, have been rejected under 35 U.S. C. 101 as 
being directed to non-statutory subject matter. The Office Action states 
that the recited "receiver" and "de-jitter module" are software constructs 
performing functionalities that do not manipulate any hardware or 
tangible entity, citing MPEP 2106. This rejection is traversed as follows. 

The subject matter of claims 22 and 32 may be partially 
enabled in software, or completely in hardware. However, it is impossible 
to enable the claimed invention completely in software. The claims recite 
a system at least partially enabled with hardware. These electrical 
hardware components may as be referred to as a machine (Guidelines 
for Subject Matter Eligibility - OG Date: 22 November 2005; Annex 
IV(c)). A "machine" is one of the four enumerated categories of patentable 
subject matter described in 35 U.S.C. 101. 

Taking claim 22 for example, a receiver is recited that 
receives an IP packet and supplies an RTP packet. The conversion 
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between protocols requires that the receiver measure the voltage levels of 
electrical signals, as referenced to a clock, to determine bit ^values; More 
explicitly, the header section of the IP packet must be "found" and 
removed, and the IP packet payload broken into RTP packets. The 
voltage measurement functions must be performed in hardware. A 
software algorithm may possibly be used to recognize patterns in the IP 
packet (i.e. the header), however, these functions are typically performed 
in hardware, since simple functions performed in hardware are almost 
always faster than equivalent functions performed with the aid of 
software. 

Claim 22 also recites a de-jitter module that accesses a 
timestamp packeiindex field and uses the timestamp to point to a PCR 
MPEG2TS in theRTP payioa& to eliminate variable transmission delay 
jitter. Again these^fuMtipM.cari be;enabled using hardware that reads 
the incoming bit values of the timestamp, and accesses a look-up table in 
memory to find a relationship between the timestamp value of the PCR 
position. Once the linkage is determined, jitter in the PGR MPEG2TS can 
removed by mapping the signal through a buffer. All these functions can 
be performed without software. Due to speed considerations, it is often 
preferable to perform all these functions in hardware. The use of 
hardware to perform the above-mentioned subject matter would be well 
understood by one with skill in the art. A similar analysis can be 
performed for the encapsulation module and transmitter recited in claim 
32. 

In summary, claims 22 and 32 do not describe a "computer^ 
related invention?', but rather a receiver and a transmitter, respectively. 
Although the claimed invention may be partially enabled using software, 
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at least some of the recited subject matter must be performed in 
hardware. Therefore, the Office Action is inaccurate when it states that 
"(t)hese functionalities do not manipulate any hardware or tangible 
entity"; 

Further, "(t)he question of whether a claim encompasses 
statutory subject matter should not focus on which of the four categories 
of subject matter a claim is directed to— process, machine, manufacture, 
or composition of matter - [provided the subject matter falls, into at least 
one;category of statutory subject matter] but rather on the essential 
characteristic of the subject matter, in particular, its practical utility" 
State Street, 149 E.3d at 1375, 47 USPQ2d at 1602. 

Since the: transmission and reception of MPEG2TS streams 
via an IP packet is process that is probably performed billions of times 
each day, the final result achieved by the claimed systems are "useful, 
tangible, and concrete". The claimed invention is "useful" in that the 
utility of the inveiltion is specific, substantial, and credible (MPEP 2107 
and Fischer, 76 USPQ2d at 1230). The claimed invention is "tangible" in 
that it falls outside the judicial exceptions (laws of nature, natural 
phenomena, abstract ideas) and has a practical application. Finally, the 
claimed invention produces a "concrete result" in that the process is 
repeatable (Guidelines for Subject Matter Eligibility - OG Date: 22 
November 2005). 

As noted in the MPEP 2107.02 IV - To properly reject a 
claimed invention under 35 U.S.C. 101, the Office Action must (A) make a 
prima facie showing that the claimed invention lacks utility, and (B) 
provide sufficient evidentiary basis for factual assumptions relied upon in 
making the prima facie showing. In re Gaubert, 524 F.2d 1222, 1224, 187 
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USPQ 664, 666 (CCPA 1975), "Accordingly, the PTO must do more than 
merely question operability - it must set forth factual reasons which 
would lead one skilled in the art to question the objective truth of the 
statement of operability/- If the Office Action cannot develop a proper 
prima facie case and provide evidentiary support under 35 U.S.C. 101, a 
rejection on this ground should not be imposed. See, e.g., In re Oetiker, 
977F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). 

The Office Action merely states that the. claimed inventions 
are software constructs performing functionalities that do not manipulate 
hardware or a tangible entity , The Applicant respectfully submits that a 
pHrna facie case for this statement has not been supported, and the 
Applicant respectfully requests that the rejection be removed. 

In Section 5 of the Office Action claims 1, 3-12, 14-22, 24-32, 
and 34-40 have. been rejected under 35 U.S.C 102(e) as anticipated by 
Ueda et al. ("Ueda"; US 2004/0190459). The Office Action states that 
Ueda discloses all the limitations of claims 1, 12, 22, and 32 in paragraphs 
[0009-0010, .0074-0075, and 0122-0123]. 

The Office Action states that Ueda discloses the limitation of 
an index field in an RTP packet header, citing paragraphs [0009-0010], 
[0074-0075], and Fig. 25. In the .Response to Arguments Section, the 
Office Action states that Ueda discloses the limitation of using the index 
to point to a PCR MPEG2TS randomly positioned in the RTP packet 
payldad, citing 504, Fig. 25, [0095]. The Office Action states that the 
storage area is maintained by using indexes (Fig. 4, [0095], and [0099]. 
This rejection is traversed as follows. 
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Fig. 25 is a diagram showing the configuration of RTP 
process unit 500 employed in the conventional communications 
apparatus" [0008] . Reference designator 504 is described as PGR 
registers. Packet synthesis unit 506 generates RTP a timestamp from the 
value of the PGR filed stored in the PGR register 504 [0010] . These 
paragraphs do not disclose a timestamp index carried in an RTP packet 
header, or a timestamp index that points to a PCR MPEG2TS randomly 
positioned in the RTP packet payload. 

Paragraphs [0000-0010] in Ueda disclose a conventional 
process where MPEP2 TS packets are carried in ah RTP packet. The 
process generates a timestamp from the PCR field, which is included in 
the RTP header. These paragraphs do not disclose a timestamp index 
carried in an RTP packet header, or a timestamp index that points to a 
PCR MPEG2TS randomly positioned in the RTP packet payload. 

Ueda's paragraphs [0074 and 0075] disclose a transmission 
process that generates ah RTP packet by adding' ah RTP header to a TS 
(Fig; 1). The RTP header includes an RTP timestamp and RTP sequence 
number. A reception process depacketizes the payload from the RTP 
packet. A timer 130 is used to measure the arrival times and arrival time 
• jitter is computed. These paragraphs do not disclose a timestamp index 
carried iii an RTP packet header, or a timestamp index that points to a 
PCR MPEG2TS randomly positioned in the RTP packet payload. 

Paragraph [0095] describes a storage area for storing 
information concerning RTP packets, which is managed by ah index. The 
information stored includes headers, start addresses, and data lengths. 
The Applicant notes that Ueda does not disclose a PCR MPEG2TS stored 
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in the storage area. Further, Ueda's disclosed index is not carried as a 
timestamp packet index in an RTP packet header. 

Paragraph [0099] discloses a management means that stores 
a payload in a buffer, arid records the start address, data length, and RTP 
header. An index maintains a correspondence between the stored 
information and an RTP sequence number. The sequence numbers permit, 
the stored packets to be arranged in the correct drdier, in the event they 
are received at ihcorrect. times due to the effectof the network. 
Paragraphs [0095] and [0099] do not disclose a timestamp index carried in 
an RTP packet header, or a timestamp index that points to a PGR 
MPEG2TS randomly positioned in the RTP packet payload. 

Thus, none of the above-cited sections from Ueda describe a 
process that accesses an index field in a RTP packet header, or that uses 
the index to locate a PGR MPEG2TS randomly positioned in the RTP 
payload (claims 1, 22, and 41). Neither does Ueda describe a process that 
encapsulates an index field to a RTP packet header for use in locating a 
PCR MPEG2TS that is randomly positioned in the RTP payload (claims 
12, 32, and 43). 

"A claim is anticipated only if each arid every element as set 
forth in the claim is found, either expressly or inherently described, in a 
single prior art reference/' Verdegdal Bros. v. Union Oil of California, 814 
FM 628, 631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987). 

Ueda does disclose every limitation of claims 1, 12, 22, and 
32. Since Ueda does hot disclose every limitation of the claimed invention, 
he cannot anticipate. Claims 3-4, 7-8, and 11, dependent from claim 1, 
claims 14-15 and 18-19, dependent from claim 12, claims 24-25, 28, and 
31, dependent from claim 22, claims 34-35 and 38, dependent from claim 
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32, claim 42, dependent from claim 41, and claim 44, dependent from 
claim 43, enjoy the same distinctions from the cited prior art. 



In Section 24 of the Office Action, claims 2, 13, 23, and 33 
have been rejected under 35 U.S.C. 103(a) with respect to Ueda in view of 
Ando etal. ("Ando"; US 7,274,863). The Office Action acknowledges that 
Ueda fails to disclose a timestamp resolution of 500 hs, but that Ando 
discloses this; feature, and that it would have been obvious to modify Ueda 
to include the teachings of Ando; to synchronize the timestamp with the 
value stored in the TS packet. This rejection is traversed as follows. 

The obviousness rejection is based upon the assumption that 
that Ueda discloses all the limitations of the base claims 1, 12, 22, and 32. 
However, even if An do's timestamp resolution is added to Ueda, the 
combination of references fails to disclose the limitations of accessing an 
index field in a RTP packet header , or using the index to locate a PGR 
MPEG2TS that is randomly positioned in the RTP payload, as recited in 
Applicant's; claims 1 and 22. Neither does the combination of references 
describe a process that encapsulates ah index field to a RTP packet header 
for use in locating a PCRMPEG2TS that is randomly positioned in the 
RTP payload, as recited in claims; 12 and 32. 

Further, the motivation of synchronization does not suggest 
modifications to Ueda that would make the Applicants claim limitations 
obvious; based on either the Ando reference, or what was well known at 
the time. Since the. combination of references neither explicitly discloses 
all the claim limitations, nor suggests modification to Ueda that would 
make all the limitations obvious, the Applicant requests that the rejection 
of claims 2, 3, 23, and 33 be withdrawn. 
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The Response to Arguments Section of the Office Action 
states that the Applicant's arguments have been directed to the, references 
individually, citing In re Keller). The Applicant respectfully disagrees. 
Rather, the AppUcarit argues that the combination of references does not 
comprise all the limitation recited in the claimed invention. The 
Applicant also argues that the combination of references fails to suggest 
that the limitations missing from combining references, do not suggest 
modifications that make, these limitations obvious. 

It is believed that the appticatifin isdn^condition for 
allowance and reconsideration is earh^stly^ solicited. 
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